In the currently existing mechanism, by using the Presence Authorization Policies the Presentity can tell the Presence Server who are authorized to watch his/her Presence Information and, if authorized to watch, what part of his/her Presence Information they can see. Such Presentity's Presence Authorization Policies are represented as Presence Authorization Rule XML document and stored in Presence XML Document Management Server (XDMS). The Presence Authorization Rule consists of two parts; Subscription Authorization Rule that determines who is authorized to subscribe to the Presentity's Presence Information, and Presence Content Rule that determines which contents of the Presentity's Presence Information are authorized to be delivered to the subscribing Watcher.
The following Table 1 shows the example of the Presence Authorization Rule. In this example, the rule specifies that the user with the URI of either “tel:+43012345678” or “sip:Hermione.blosson@exmaple.com” is allowed to subscribe the Presentity's Presence Information, and the subscribed user with the URI of either “tel:+43012345678” or “sip:Hermione.blosson@exmaple.com” is allowed to be provided with the ‘PoC’ service, ‘willingness’, and ‘status-icon’ related presence attributes.
<?xml version=“1.0” encoding=“UTF-8”?><cr:ruleset xmlns:op=“urn:oma:xml:prs:pres-rules”  xmlns:pr=“urn:ietf:params:xml:ns:pres-rules”  xmlns:cr=“urn:ietf:params:xml:ns:common-policy”> <cr:rule id=“ck81”>  <cr:conditions>   <cr:identity>    <cr:one id=“tel:+43012345678”/>    <cr:one id=“sip:hermione.blossom@example.com”/>   </cr:identity>  </cr:conditions>  <cr:actions>   <pr:sub-handling>allow</pr:sub-handling>  </cr:actions>  <cr:transformations>   <pr:provide-services>    <op:service-id>org.openmobilealliance:PoC-session</op:service-id>   </pr:provide-services>   <op:provide-willingness>true</op:provide-willingness>   <pr:provide-status-icon>true</pr:provide-status-icon>  </cr:transformations> </cr:rule></cr:ruleset></cr:transformations> </cr:rule></cr:ruleset>
When a Presence Server receives a SUBSCRIBE request on a Presentity's Presence Information from a Watcher, the Presence Server fetches the Presentity's Presence Authorization Rules from Presence XDMS, and uses it to authorize the Watcher with regards to subscription request and the parts of Presence Information to be delivered. The Presence Server keeps synchronized with the Presence XDMS by “xcap-diff” event package subscription such that the changes in the Presentity's Presence Authorization Rules could be instantly reflected in the Presence Server's handling of the Presence Information requests and delivery. This is called as Proactive Presence Authorization as the Presence Server can perform authorization for itself based on the predescribed static rules (i.e., Presence Authorization Rules in Presence XDMS) and without the need of direct interaction with Presentity.
Also, the Reactive Presence Authorization, where the Presence Server authorizes the Watcher's subscription requests to the Presentity's Presence Information per the Presentity's reaction on those, can be achieved by the following procedure: Firstly, the Presentity needs to subscribe for “presence. winfo” event package to Presence Server. Upon this event subscription, the Presence Server notifies the Presentity of the current status of Watcher lists and their corresponding subscription states. With this information, the Presentity can identify which Watcher is ‘pending’ subscription state and, if the Presentity wants to allow the Watcher to see his Presence Information, the Presentity revises the Presence Authorization Rule in Presence XDMS as such. Such modifications of the rules are notified to the Presence Server and then the Presence Server applies those updated Presence Authorization Rules to handle the ‘pending’ subscription requests from the Watchers. The example flows of how the current reactive Presence Authorization mechanism works are shown in FIG. 1 and the steps involved are discussed in the followings.
The following describes each step in FIG. 1:
Note: Presence Server subscribing for changes to Presence Authorization Rule documents stored in Presence XDMS is omitted from the above FIG. 1 for simplicity.
In step 100, the Presentity 20 wishing to know the list of watchers who are subscribed for his/her Presence Information sends a SIP SUBSCRIBE request to SIP/IP core 30 subscribing for “presence.winfo” event package.
In step 102, the SIP/IP core 30 forwards the request to the Presence Server 40 of Presentity's domain.
In step 103, the Presence Server 40 processes the received SIP SUBSCRIBE and upon successful processing sends 200 OK response to SIP/IP Core 30.
In step 104, the SIP/IP core 30 forwards the 200 OK response to the Presentity 20.
In step 105, the Presence Server 40 sends SIP NOTIFY request containing the details of Watchers to the SIP/IP core 30.
In step 106, the SIP/IP core 30 forwards the SIP NOTIFY request to the Presentity 20.
In step 107, the Presentity 20 sends the 200 OK responses for the SIP NOTIFY request.
In step 108, the SIP/IP core 30 forwards the 200 OK responses to the Presence Server 40.
In step 109, Watcher 50 wishing to subscribe for Presence Information of the Presentity 20 sends a SIP SUBSCRIBE request to the SIP/IP Core 30.
In step 110, the SIP/IP Core 30 forwards the SIP SUBSCRIBE to the Presence Server 40.
In step 111, the Presence Server 40 processes the received SIP SUBSCRIBE and finds out that the Watcher 50 is not authorized to subscribe for Presentity's Presence Information and hence acknowledges the SIP SUBSCRIBE with “202 Accepted” responses.
In step 112, the SIP/IP Core 30 forwards the “202 Accepted” responses to the Watcher 50.
In step 113, as soon as the presence server 40 sends a SIP 202 Accepted response to accept the subscription, it sends a SIP NOTIFY request to the Watcher 50 as mandated by [RFC3265]. At this time, the Presence Information to be delivered to the Watcher 50 may be not available yet as the Watcher has not yet been authorized to see the Presentity's Presence Information. As such, a “dummy” SIP NOTIFY request can be sent, with a valid neutral or empty Presence Information and a valid Subscription-State header field (set to “pending”) for the time being.
In step 114, the SIP/IP Core 30 forwards the SIP NOTIFY request with the ‘dummy” Presence Information to the Watcher 50.
In step 115, the Watcher 50 sends 200 OK responses to the received SIP NOTIFY request.
In step 116, the SIP/IP Core 30 forwards 200 OK response to the Presence Server 40.
In step 117, the Presence Server 40 sends a SIP NOTIFY request to the Presentity 20 which contains the detailed lists of the Watchers who have subscribed for Presentity's Presence Information and the state of the subscription which is “pending” in this case.
In step 118, the SIP/IP Core 30 forwards the SIP NOTIFY request to the Presentity 20.
In step 119, the Presentity 20 acknowledges the SIP NOTIFY request with 200 OK response.
In step 120, the SIP/IP Core 30 forwards the 200 OK response to the Presence Server 40.
In step 121a, after getting to know the Watcher's identity who is ‘pending’ subscription state, the Presentity 20 wishes to authorize the Watcher 50 to view his/her Presence Information and hence the Presentity 20 does the XCAP operations in which to update Presence Authorization Rule (RFC 4825, “The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)”). As such, the Presentity 20 changes the Presence Authorization Rule document to authorize the Watcher 50.
Note: For brevity sake, the details of XCAP operations in step 121b and the details of Presence Server getting to know the changes in the Presence Authorization Rules in Presence XDMS are not shown.
In step 122, the Presence Server 40 authorizes the Watcher 50 per the updated Presence Authorization Rule and issues another SIP NOTIFY containing the valid Presence Information which he/she is authorized to view per the updated Presence Authorization Rule.
In step 123, the SIP/IP Core 30 forwards the SIP NOTIFY to the Watcher 50.
In step 124, the Watcher 50 sends 200 OK response for SIP NOTIFY request.
In step 125, the SIP/IP Core 30 forwards the 200 OK response to the Presence Server 40.